Data storage access device

ABSTRACT

A data storage access device for providing access by an external device to data stored according to a first file system on physical storage, comprises a file system interface operator ( 8 ) for providing a file system interface to the external device, wherein the file system interface represents data stored on the physical storage according to the first file system as being stored according to a second file system.

FIELD OF THE INVENTION

The present invention relates to a data storage access device, and tomethods of performing file system operations on data storage devices.The invention relates, for example, to a data storage access deviceforming part of a mobile peripheral device (such as a portablenavigation device, a mobile phone, a portable games machine, a camera,an MP3 or other portable music player, a video camera or video player)that can be connected to a host computer for the performance of filesystem operations, for example uploading or downloading of data, by thehost computer.

BACKGROUND TO THE INVENTION

A wide variety of electronic devices now include memory for storage ofdata. Flash memory devices for instance have become increasinglycommonly used either as permanently installed internal data storagedevices or as removable data storage devices, for example memory cards.

Smart mobile peripheral devices (for example, portable navigationdevices, mobile phones, portable games machines, cameras, MP3 or otherportable music players, video cameras or video players) usually includea memory for storing files. When connecting such smart mobileperipherals with file storage to a computer, the file storage should beaccessible to the computer. When disconnected, the file storage shouldbe usable by the device itself, at which point the device is usuallyrunning on battery power.

The most common way to make the file storage of the peripheral deviceaccessible to a computer is to expose the raw storage hosting the filestorage of the peripheral device to the computer when the device isconnected to the computer. Upon connection of the peripheral device tothe computer, the computer accesses the file storage by sending a readrequest for the boot sector of the storage. If the computer determinesthat the raw storage is formatted using a file system type that is knownto the computer, the computer can than access the file storage of theperipheral device using that file system.

However, this introduces a trade off in the file storage technologychoice, in particular the type of file system used by the peripheraldevice. A known approach is to use a file allocation table (FAT) filesystem such as Microsoft VFAT/FAT32 for the file store of the device.Files stored on the device can be accessed in a straightforward mannerby a host computer when the underlying storage of the device is exposedto the operating system of the host computer, as such file systems arealmost universally used in personal computers. However, the choice of aFAT file system such as a Microsoft VFAT/FAT32 file system may not beoptimal for use by the device, particularly if it is a battery powereddevice as due to lack of journaling features provided by such filesystems reading to or writing from such file systems is not power-failsafe. For example, the relationship between file contents and filemetadata, as well as the internal consistency of the file system may bedamaged by a power failure, in particular if the power failure occursduring a write operation.

Some electronic devices monitor power levels and ensure a safe shutdownif power is close to being exhausted. However, even in the case of suchdevices, problems can occur if a removable data storage device isforcibly removed during a read or write operation, or if power failureoccurs due to an unforeseen device or component failure.

Power failure problems can be particularly acute in an automotiveenvironment, as power is often delivered by the vehicle battery toelectronic devices associated with the vehicle. Examples of suchelectronic devices in an automotive environment include navigationdevices, for example portable navigation devices (PNDs). The software,or other control system, of such electronic devices may have little orno control over the level of power delivered. For example, during anengine start, power can drop to dangerously low levels especially if thevehicle battery is old. That may cause corruption of data if a non-powerfail safe file system, such as FAT, is used.

More generally, power failure problems can occur if an SD card, or anyother removable memory device, is removed from a device or computer, forexample a PC, whilst the SD card or memory device is being written to.

FAT file systems or other PC-compatible power systems may not be themost appropriate for a device, depending on the nature of the device.Many highly optimized file systems exist for peripheral or otherelectronic devices but they cannot be read or written by a standard PCdirectly and therefore are often not used despite their greatersuitability for operation of the devices

It is an aim of the present invention to provide an improved, or atleast alternative, device and method for accessing stored data.

SUMMARY OF THE INVENTION

In a first, independent aspect of the invention there is provided a datastorage access device for providing access by an external device to datastored according to a first file system on physical storage, the datastorage access device comprising: a file system interface operator forproviding a file system interface to the external device, wherein thefile system interface represents data stored on the physical storageunder the first file system as being stored under a second file system.

Thus, a desired file system for data stored on the physical storage canbe used, whilst still maintaining compatibility with a file system usedby the external device. For example, a power-safe file system can beused, regardless of whether the external device is configured to usethat, or any, power-safe file system.

Alternatively or additionally, a file system can be used which supportsfile attributes not generally understood by file systems that might beused on the external device, such as file owners, or access controllists. Furthermore, the operating system of the host computer need notbe modified to deal with the subtleties of a file system optimized foruse in the data storage device.

The external device may comprise a desktop or laptop computer, forexample a PC or Mac. The file system interface operator may comprise adriver or other executable software, hardware or combination of softwareand hardware. The file system interface operator may comprise one ormore modules. The data may comprise a file, sub-directory, rootdirectory or boot sector.

The data storage access device may include the physical storage.Alternatively the physical storage may be external to the data storageaccess device.

The file system operator may comprise a file system driver for the firstfile system.

The data storage access device may further comprise a processingresource, for example a processor. The processing resource may beoperable to perform file system operations using the first file systemon data stored on the physical storage. The file system interfaceoperator may be stored on the physical storage and may be readableand/or executable from the physical storage by the processing resource.

The device may further comprise, or being configured to communicatewith, a file system operator for accessing data on the physical storageaccording to the first file system.

The file system operator may comprise a file system driver. The filesystem operator may be stored on the physical storage and may bereadable and/or executable from the physical storage by the processingresource.

The first file system may be of a first type and the second file systemmay be of a second, different type.

The file system interface operator may be configured to intercept arequest according to the second file system from the external device andto perform the request using the first file system.

The file system interface operator may be configured to respond to therequest with a response in a response format of the second file system.For example, the response may comprise metadata of the second filesystem. The metadata may be indicative that the data is stored under afile system of the second type. The response may exclude any metadata ofthe first file system.

The file system interface operator may be configured to assign at leastone logical storage element of the second file system to a file storedin the first file system.

The file system interface operator may be configured to map at least onelogical storage element of the second file system to at least onestorage element of the first file system.

The file system operator may be configured to generate a file allocationtable that allocates files stored on the physical storage to logicalstorage elements of the second file system.

The request may comprise a request to perform an operation on at leastone logical storage element of the second file system, for example arequest to read or write at least one logical storage element of thesecond file system.

The file system interface operator may be configured to translate therequest into a request according to the first file system.

The file system interface operator may be configured to translate therequest into a request to perform an operation on at least one logicalor physical storage element of the first file system, for example arequest to read or write at least one logical storage element of thefirst file system.

The file system operator may be configured to translate the request intoa request to perform a file operation according to the first filesystem, and then to translate the request to perform a file operationinto a request to perform an operation on a logical or physical storageelement of the first file system. The file operation may comprise atleast one of a read request; a write request; an open file,sub-directory or directory request; a close file, sub-directory ordirectory request; a move file, sub-directory or directory request; asave request, or a rename request.

The file system interface operator may be configured to respond to aread request by the external device by providing a response thatcomprises as at least one logical storage element of the second filesystem.

The file system interface operator may be configured to receive a writerequest to write to at least one logical storage element of the secondfile system, to determine at least one storage element of the first filesystem corresponding to the at least one logical storage element of thesecond file system, and to write the data to the at least one storageelement of the first file system.

The or each logical storage element of the second file system maycomprise a block or sector. The storage element of the first file systemmay comprise a block, sector or cluster.

The file system interface operator may be configured to respond to aread request for the boot sector of the physical storage with a responsethat indicates that the physical storage is formatted according to afile system of the second type.

The file system interface may comprise representations of files,directories and/or sub-directories in the second file system thatcorrespond to files, directories and/or sub-directories stored in thephysical storage under the first file system.

The file system interface operator may be configured to update the filesystem interface in response to changes to files, directories orsub-directories stored in the physical storage under the first filesystem so that the file system interface represents the changes asoccurring under the second file system.

The file system interface operator may represent the changes asoccurring under the second file system by modifying metadata of thesecond file system.

The metadata of the second file system may comprise at least one of:filename; file size; directory or sub-directory name; directory orsub-directory size; file, sub-directory or directory history data; readtime; and write time.

The file system interface may be configured to represent at least someof the data stored on the physical storage under the first file systemas being stored under the second file system, and to represent at leastsome of the data stored on the physical storage under the first filesystem as being stored under at least one further file system. The filesystem of the first type may comprise an Ext-type file system. The Extfile system may comprise an Ext3 file system or a successor to the Ext3file system.

The file system of the second type may comprise a FAT-based file systemor NTFS file system. The FAT-based file system may comprise one of aFAT, vFAT, FAT16, or FAT32 file system.

The physical storage may comprise NAND flash storage, and the first filesystem may comprise a log-structured file system, for example JFFS2. Ina further independent aspect of the invention there is provided a methodof accessing data stored under a first file system on a data storagedevice comprising providing a file system interface that represents datastored on the data storage device under the first file system as beingstored under a second file system,

The first file system may be a file system of a first type and thesecond file system may be a file system of a second, different type.

The method may comprise intercepting a request according to the secondfile system and performing the request using the first file system.

The method may comprise responding to the request with a response in aresponse format of the second file system.

The request may comprise a request to perform an operation on at leastone logical storage element of the second file system, for example arequest to read or write at least one logical storage element of thesecond file system.

The method may comprise translating the request into a request accordingto the first file system.

The method may comprise translating the request into a request toperform an operation on at least one logical or physical storage elementof the first file system, for example a request to read or write atleast one logical or physical storage element of the first file system.The method may comprise responding to a read request by providing aresponse that comprises as at least one logical storage element of thesecond file system.

The method may comprise receiving a write request to write to at leastone logical storage element of the second file system, to determine atleast one storage element of the first file system corresponding to theat least one logical storage element of the second file system, and towrite the data to the at least one storage element of the first filesystem.

The method may comprise responding to a read request for the boot sectorof the physical storage with a response that indicates that the physicalstorage is formatted using a file system of the second type.

The method may comprise representing files, directories and/orsub-directories stored in the physical storage under the first filesystem as files, directories and/or sub-directories in the second filesystem.

The method may comprise updating the file system interface in responseto changes to files, directories or sub-directories stored in thephysical storage under the first file system so that the file systeminterface represents the changes as occurring under the second filesystem.

The method may comprise representing at least some of the data storedunder the first file system as being stored under the second filesystem, and to represent at least some of the data stored under thefirst file system as being stored under at least one further filesystem. The method may comprise representing the changes as occurringunder the second file system by modifying metadata of the second filesystem.

In a further independent aspect of the invention there is provided acomputer program product comprising computer readable instructions thatare executable to perform a method as claimed or described herein.

The computer readable instructions may be executable by the processor ofan electronic device, for example a mobile peripheral device such as aportable navigation device, a mobile phone, a portable games machine, acamera, an MP3 or other portable music player, a video camera or videoplayer.

There may also be provided an apparatus or method substantially asdescribed herein with reference to the accompanying drawings.

Any feature in one aspect of the invention may be applied to otheraspects of the invention, in any appropriate combination. For example,device features may be applied to method features and vice versa.

DETAILED DESCRIPTION OF EMBODIMENTS

Embodiments of the invention are now described, by way of non-limitingexample, and are illustrated in the following figures, in which:

FIG. 1 is a schematic diagram of a data storage device according to oneembodiment;

FIG. 2 is a schematic diagram of a navigation device;

FIG. 3 is schematic representation of an architectural stack of thenavigation device of FIG. 2;

FIG. 4 is a schematic representation of the data structure of a filesystem of the data storage device;

FIG. 5 is a schematic diagram showing the navigation device of FIG. 2connected to a computer;

FIG. 6 is a schematic diagram of a file system interface driver of thedata storage device of FIG. 1;

FIG. 7 is a flowchart illustrating in overview a read operation andsubsequent write operation; and

FIG. 8 is a schematic diagram showing the correspondence between a rootdirectory, sub-directory and files of a file store of the data storagedevice of FIG. 1 and root directory, sub-directory and files in avirtual file system interface provided by the file system interfacedriver of FIG. 6.

Embodiments of the present invention will now be described, by way ofexample only.

A data storage device 2 that can be accessed by a data storage accesssystem according to a first embodiment is illustrated in FIG. 1. Thedata storage device 2 may be inserted into an electronic device and usedfor data storage by the electronic device. In the embodiment of FIG. 1,the data storage device 2 is intended for use in a navigation device 20,but it can be used in any suitable electronic device, for example amobile phone, a portable games machine, a camera, an MP3 or otherportable music player, a video camera or video player.

The data storage device 2 is in the form of an SD card comprising a filesystem 4 (in this case an Ext3-file system) in which can be stored aplurality of data and other files 6. The files include variousexecutable program files, including applications, operating systemcomponents and drivers. The files include a file storing a file systeminterface driver 8, which is executable to provide a file systeminterface to enable a host computer to access the data storage deviceusing a different file system to that used by the data storage device 2itself, as will be described in more detail below.

The navigation device 20 is illustrated in FIG. 2, and provides aprocessing resource that is operable to execute the file systeminterface driver 8 when the storage device 2 is installed in thenavigation device. The file system interface driver 8 provides a filesystem interface to enable a host computer to access the data storagedevice 2 using a different file system to that used by the data storagedevice 2 itself, as will be described in more detail below. Thenavigation device 20 can thus operate as a data storage access deviceenabling access to the storage device 2 by external devices.

The navigation device 20 is located within a housing (not shown). Thehousing includes a processor 22 connected to an input device 24 and adisplay screen 26. The input device 24 can include a keyboard device,voice input device, touch panel and/or any other known input deviceutilised to input information; and the display screen 26 can include anytype of display screen such as an LCD display, for example. In onearrangement the input device 24 and display screen 26 are integratedinto an integrated input and display device, including a touchpad ortouchscreen input so that a user need only touch a portion of thedisplay screen 26 to select one of a plurality of display choices or toactivate one of a plurality of virtual buttons.

The navigation device may include or be connected to an output device28, for example an audible output device (e.g. a loudspeaker or vehicleradio). As output device 28 can produce audible information for a userof the navigation device 20, it should equally be understood that inputdevice 24 can include a microphone and software for receiving inputvoice commands as well.

In the navigation device 20, processor 22 is operatively connected toand set to receive input information from input device 24 via aconnection 30, and operatively connected to at least one of displayscreen 26 and output device 28, via output connections 32, to outputinformation thereto. Further, the processor 22 is operably coupled tothe data storage device 2 via connection 36 and to an internal Flashmemory 37 (in this case a MoviNand device) via connection 39. Theprocessor 22 is further adapted to receive/send information from/toinput/output (I/O) ports 38 via connection 40, wherein the I/O port 38is connectible to a further I/O device 42 external to the navigationdevice 20. The navigation device 20 also comprises a volatile memory(not shown) such as a Random Access Memory (RAM).

FIG. 2 further illustrates an operative connection between the processor22 and a GPS antenna/receiver 44 via connection 46. The antenna/receiver44 are combined schematically for illustration purposes but may beseparately positioned components. The antenna can be, for example, a GPSpatch antenna or helical antenna.

Referring now to FIG. 3 of the accompanying drawings, the internal flashmemory 37 stores a boot loader program that is executable by theprocessor 22 in order to load an operating system 50 and applicationsoftware from the storage device 2 for execution by functional hardwarecomponents, which provides an environment in which the applicationsoftware 52 can run. The operating system 50 serves to control thefunctional hardware components and resides between the applicationsoftware 52 and the functional hardware components. It can be seen thatthe operating system 50 includes the file system interface driver 8. Theoperating system also includes standard file system drivers foraccessing the file system 4 (in this case the Ext3 file system) used bythe storage device 2.

The application software 52 provides an operational environmentincluding a GUI that supports core functions of the navigation device20, for example map viewing, route planning, navigation functions andany other functions associated therewith. In variants of the describedembodiment, the operating system 50 and/or the application software 52are stored on the Flash memory 37. The file system interface driver 8can also be stored in the Flash memory 37 rather than in the storagedevice 2 according to some of those variants. In some furtherembodiments no internal flash memory 37 is included in the device 20,and the boot loader, operating system 50 and application software 52 areall stored on the storage device 2.

Data that is used by the application software, including map data, canbe stored on the data storage device 2. The operating system andapplications are installed in the volatile memory of the device uponstart-up.

In the embodiment of FIGS. 1 and 2, the file system 4 is an Ext3 filesystem and the processor 22 of the navigation device is able to performread, write and other standard operations on files stored in the datastorage device by using known Ext3 file system drivers included in theoperating system 50. The Ext3 file system provides journalingcapabilities and thus can provide for power-fail safe operation.

As shown in FIG. 4, the Ext3 file system 4 comprises a boot area 70, aninode area 72, and a data area 76. The boot area 70 contains basicinformation concerning the Ext3 file system, for example cluster andsector sizes, and the size and location of the inode area 72. The inodearea 72 contains metadata in the form of inodes representative ofproperties of the files stored in the Ext3 file system, for example,file type, file size, one or more attributes (for example whether a fileis read-only, or access privileges), and time stamps representative oftime of creation and/or modification, if required, as well as theidentity and location of the clusters in the data area 76 containing thefile data. Each inode is 128 bytes in size, and extended attributes arenot used. The data area 76 contain the file data, and also containsdirectory data (comprising at least root directory data) and journalentries that are used to journal data and/or metadata during the writingof data and metadata by the file system.

The navigation device 20 can be connected to a PC or other computer toenable data (for example log data concerning use of the navigationdevice) to be transferred to the computer, or to enable data (forexample software upgrades, or map or other data) to be transferred fromthe computer to the navigation device 20 and stored in the storagedevice 2. FIG. 5 shows the navigation device 20 connected to a PC 100via a USB cable 102. The PC 100 includes an application layer 104 thatcomprises application software, and a known operating system 106 (forexample, MS Windows or Mac OS X) that includes a FATNFAT/FAT-32 driver108 in its kernel. When the navigation device 20 is connected to thepersonal computer 100, a user can perform functions relating to thenavigation device 20 via the functionality provided by the applicationsoftware 104 running on the personal computer 100.

In the arrangement shown in FIG. 5, the PC 100 does not include any Ext3file system drivers. Nevertheless, the PC 100 is able to performoperations on files (for example, reading, writing or deleting files)stored using the Ext3 file system 6 on the data storage device 2, viaoperation of the file system interface driver 8.

In operation, the file system interface driver 8 intercepts read andwrite requests received from the computer 100, and provides a filesystem interface to the computer 100. The interface provided to thecomputer 100 does not directly represent the raw storage device 2 butinstead appears as a block-structured storage device containing a FATfile system.

The structure of the file system interface driver 8 is shown in moredetail in FIG. 6. The file system interface driver includes aninterception module 120 that is operable to intercept read requests andother file system requests from a computer or other external apparatus.The file system interface driver also includes a virtual file systemcreation module 122, a mapping module 124, and an output module 126.

The virtual file system creation module 122 is operable to create avirtual file system corresponding to the file system 8 of the storagedevice 2. The virtual file system is of a different type (for example,VFAT or FAT32) to that of the file system of the storage device 2 (forexample Ext3). The choice of which type of file system to use as thevirtual file system in a particular embodiment can depend on theparticular application for which the embodiment is to be used, and onthe size or content of the stored files. For example, FAT16 is supportedmore widely than FAT32, but FAT32 can hold more than 2 GB of data, andin that case a choice between FAT16 and FAT32 may depend on the size ofthe Ext3 or other type of file system of the physical storage.

In embodiments in which the device presents a FAT file system interfaceto the computer 100, the virtual file system creation module 122generates a file allocation table that allocates files stored on thephysical storage to logical storage elements of the second file system

The mapping module 124 is operable to map files, directories,sub-directories and file system logical elements (for example sectors orblocks) of the virtual file system to files, directories,sub-directories and file system logical or physical storage elements(for example sectors, blocks or clusters) of the file system 8, or viceversa. The output module 126 is operable to receive requests or datafrom one of the computer or the storage device 2, to modify the requestsor data based upon mappings by the mapping module 124 and to output themodified request or data to the other of the computer or storage device2.

In one mode of operation, when a read request for the boot sector of thestorage device 2 (for example a request for sector 0) arrives, the filesystem interface driver 8 responds with a prepared response comprising afake FAT boot sector (a fixed 512 byte data structure) that indicatesthat the storage device is formatted using a file system used by thecomputer, in this case FAT32. The response from the file systeminterface driver in this example includes the string “FAT32” at offset0×52 and the bytes 0×55 0×AA at offsets 0×1 FE.

The computer 100 receives and processes the response and determines thatthe storage device is using a FAT32 file system (although the storagedevice is in fact using an Ext3 file system). In this example, if thefile system interface driver 8 were not present then the responsereturned to the external device to the boot sector request wouldindicate, correctly, that the storage device was using an Ext3 filesystem. In that case the external device, in this case a PC would giveup as it does not include Ext3 file system drivers.

In normal operation, in order to access data stored on the data storagedevice 2 the computer 100 would next transmit a read request for theFAT32 root directory to the device 20. When the read request for theFAT32 root directory arrives, the file system interface driver 8intercepts it, and then retrieves the root directory of the actual filestorage (which in this case uses Ext3 rather than VFAT/FAT32) andcreates a synthetic VFAT/FAT32 root directory in memory (for example inthe navigation device RAM). Each entry in this VFAT/FAT32 directorycorresponds to an entry in the “exposed root” directory of the filestorage. As VFAT supports both “long” and “short” names for a singlefile, there might be two VFAT entries for a single physical file.

In one mode of operation, if the computer 100 attempts to write tosector 0 the interception module 120 will report a write failure,preventing any attempt by the computer 100 to reformat the device. Inanother mode of operation, if the computer 100 attempts to write tosector 0 in order to reformat the device, the file system interfacedriver 8 reads a file system identifier included in the request from thecomputer 100, reformats the device and then provides to the computer afile system interface comprising a file system of the type determinedfrom the file system identifier included in the reformat request.

For example, the physical storage device may include an Ext3 file systemand the file system interface driver 8 may by default provide a filesystem interface representing the data on the physical storage as beingstored under a FAT32 file system. If the file system interface driver 8then receives from the computer 100 a request to write to sector 0 for aFAT16 file system, the file system interface driver 8 in one mode ofoperation alters the file system interface in response so that itsubsequently represents data stored on the physical storage as beingstored under the FAT16 file system, thus enabling the computer 100 toperform operations on the physical storage via the file system interfacedriver 8. If the request was received as part of a reformat request thenthe file system interface driver 8 may also remove all existing filesand directories from the physical storage, for example by writing newfile system data representative of an empty disk. Alternatively, thefile system interface driver 8 may represent to the computer 100 underthe virtual file system that all existing files and directories had beenoverwritten whilst retaining them on the physical storage.

The entries (for example files and sub-directories) in the rootdirectory include unique virtual block numbers that the computer 100interprets as representing the location of the data blocks correspondingto the files and sub-directories in accordance with usual FAT32 filesystem.

In fact, the virtual block numbers do not relate to actual physicalstorage locations but are used in future requests.

An application at the computer 100 may then create a read request a fileor directory stored under the virtual FAT file system. The operatingsystem at the computer 100 converts the read request into a FAT fileread request, and a FAT file system driver at the computer 100translates the request into one or more FAT sector read requests. Theone or more sector read requests include identifiers identifying the FATblock in which the sector(s)s are located.

When the read request arrives from the computer 100 at the file systeminterface driver 8, the driver 8 translates the request back into a FATfile read request and checks whether the block number included in therequest corresponds to a directory or file entry in the virtual filesystem. If it is a file entry, the driver 8 maps the block number to theoriginal filename, translates the FAT file read request into a readrequest according to the Ext3 file system, in this embodiment, andreturns the corresponding bytes of data from the file in the file storeof the storage device 2 using the Ext3 file system drivers to access thedata.

If the block number refers to a subdirectory, a synthetic subdirectoryis created in the virtual file system. This process is similar to thecreation of a synthetic root directory except that the entries are takenfrom the corresponding subdirectory on the file store rather than fromthe root directory on the file store. The driver 8 reads thecorresponding sub-directory from Ext3 file system andreformats/translates the contained sub-directory entries to correspondto the FAT format, for example it removes or replaces Ext3-specificinformation. An example of information that is removed is an identifieridentifying the file owner or creator (Ext3 stores such an identifier inthe file's directory entry, FAT doesn't store it at all).

A similar process is followed to perform write operations. A writeoperation is interpreted by the file system interface driver 8 asrelating to either a file write or a directory modification, and thedriver 8 then passes corresponding instructions to the Ext3 file systemdriver. It some cases due to write reordering a physical write cannot beclassified immediately as either a file write or a directorymodification. In that case the data written is held in reserve by thefile system interface driver 8 until it can be classified, after whichthe file store is updated accordingly.

If the computer 100 wishes to modify a retrieved file it can return themodified data as modified blocks, in accordance with normal FAT32techniques. However, instead of writing the modified blocks to physicalstorage using normal FAT32 techniques, the mapping module 124 insteaddetermines which Ext3 storage elements correspond to the modifiedvirtual blocks and the output module 126 writes to those Ext3 storageelements on the physical storage device 2 via the Ext3 file systemdrivers included in the navigation device 20.

A flowchart illustrating in overview one mode of operation of the filesystem interface driver 8 is provided in FIG. 7.

In some modes of operation each entry (file, sub-directory, directory)in the file store of the storage device 2 has a corresponding entry inthe virtual file system.

In other modes of operation, the device may expose only part of its filestore to the computer 100. For example the device may ensure that thesynthetic FAT root directory does not coincide with the root directoryon the storage device 2, but instead the mapping module 124 may map thesynthetic root directory to another directory or sub-directory stored onthe storage device 2.

FIG. 8 illustrates the correspondence between a subdirectory (namedVroot) 140, files 142, 144, 146, 150, 152 and a further sub-directory148 stored in the file store of the storage device 2 and a correspondingsynthetic root directory 160, files 162, 164, 166, 170, 172 andsub-directory 168 created by the file system interface driver 8 andstored as a virtual file system in RAM of the device 20. In this case,the synthetic root directory 160 maps to the Vroot sub-directory of theExt3 file system rather than to the actual Ext3 root directory. Filecontent for the synthetic files is not stored in the RAM. Instead, asdescribed above, if the content of such synthetic files is requested bythe computer 100 or other external device it is obtained by the filesystem interface driver 8 from the physical storage device 2 using theExt3 file system drivers.

In operation the file system interface driver 8 modifies the virtualfile system to match modifications to the actual file system. Forexample, the file system interface driver 8 deletes file orsub-directory entries from the virtual file system in response to thecorresponding files or sub-directories being deleted from the storagedevice 2.

The file system interface driver 8 maintains and stores in RAM metadata(for example, filename, file location, file size, directory name,directory location, directory size, file or directory history data, readtime, and write time) for the virtual file system, and representschanges by modifying the metadata of the virtual file system. Anyoperations performed by the computer on the data stored in the datastorage device 2 via the file system interface driver 8 can berepresented by modifications to the virtual file system metadata storedin the RAM. For example, if the computer or other external devicerequests that a file be moved from one sub-directory to anothersub-directory, that operation is performed by the file system interfacedriver 8 sending a corresponding request via the Ext3 file systemdrivers. The Ext3 file system metadata stored on the physical storagedevice 2 is modified to reflect the change in location of the file inthe Ext3 file system. In addition, the virtual file system metadata (inthis case FAT32 metadata) stored in RAM and available to the computer100 or other external device is also modified to reflect the change.

In alternative embodiments the metadata mentioned in the precedingparagraph is stored or other volatile memory instead of RAM, or isstored in non-volatile memory, or is regenerated whenever it is needed.

In alternative embodiments the file system interface driver isconfigured to provide an interface between other types of file system,for example between any combination of: NTFS, any type of FAT filesystem (for example FAT12, FAT16, FAT32), UDF, Ext2, Ext3, Ext4, Btrfs,or JFFS2. For example, in certain embodiments, on the computer side thefile system is one of CDFS (usually used by CDs), UDF (usually used byDVDs), NTFS, or any type of FAT file system, and on the device side thefile system is one of Ext3, Ext4, Btrfs, JFFS2 or any otherlog-structured file system.

In one embodiment the physical storage of the device is NAND flashmemory. A JFFS2 file system is used on the NAND flash memory. JFFS2 filesystems or other log-structured file systems are often used for NANDflash memory devices as such devices only allow large (for example 128KB) blocks of data to be erased, and as some blocks of memory areunusable after production and others fail over time. The use of alog-structured file system protects the integrity of the stored data inthe event of such failures. In the embodiment, a file system interfacedriver 8 maps the JFFS2 file system to a virtual FAT-based interface,thus enabling a PC or other external device to access data stored on theflash memory without requiring the PC or other external device toinclude JFFS2 drivers.

In other embodiments the file system interface driver 8 is configured tooperate such that the virtual file system creation module 122 createstwo or more different virtual file system of different types (forexample one FAT16 file system and one FAT32 file system) to representthe file system of the device. The mapping module 124 is configured tomap different files, sub-directories, root directory, and sectors orblocks of the device to one or other of the different virtual filesystems.

In the embodiment of FIGS. 1 and 2 the physical storage that stores dataunder the first file system is included in physical device (thenavigation device 20) that provides the file system interface driverthat enables access to the data using an file system interfacecomprising a virtual file system. In other embodiments the physicalstorage is separate from the device that includes the file systeminterface driver or other file system interface operator. For example,in one such embodiment a processing resource operable to provide thefile system interface driver or other file system interface operator forproviding the file system interface is included in an SD card readerthat can accept EXT-formatted SD cards and create a virtual FAT filesystem enabling access to data on the SD cards by a PC or other deviceusing a FAT file system.

In another embodiment, a processing resource operable to provide thefile system interface driver or other file system interface operator forproviding the file system interface is included in an adapter box thatcan be connected on one side to a USB disk (formatted under Ext3, forexample) and on the other side to a PC. The adapter box would beoperable to represent the USB disk as a FAT-formatted disk, or as beingformatted according to any other desired format.

Embodiments, or features of such, can be implemented as a computerprogram product for use with a computer system, the computer programproduct being, for example, a series of computer instructions stored ona tangible data recording medium, such as a diskette, CD-ROM, ROM, orfixed disk, or embodied in a computer data signal, the signal beingtransmitted over a tangible medium or a wireless medium, for example,microwave or infrared. The series of computer instructions canconstitute all or part of the functionality described above, and canalso be stored in any memory device, volatile or non-volatile, such assemiconductor, magnetic, optical or other memory device.

It will also be well understood by persons of ordinary skill in the artthat whilst embodiments implement certain functionality by means ofsoftware, that functionality could be implemented solely in hardware(for example by means of one or more ASICs (application specificintegrated circuit)) or by a mix of hardware and software. As such,embodiments are not limited only to being implemented in software.

It will be understood that the present invention has been describedabove purely by way of example, and modifications of detail can be madewithin the scope of the invention.

Each feature disclosed in the description, and (where appropriate) theclaims and drawings may be provided independently or in any appropriatecombination.

1. A navigation device for providing access by an external device todata stored according to a first file system on physical storage,comprising: a file system interface operator for providing a file systeminterface to the external device, wherein the file system interfacerepresents data stored on the physical storage according to the firstfile system as being stored according to a second file system, whereinthe first file system is a power-safe file system.
 2. A device accordingto claim 1, further comprising: being configured to communicate with, afile system operator for accessing data on the physical storageaccording to the first file system.
 3. A device according to claim 1,wherein the first file system is of a first type and the second filesystem is of a second, different type.
 4. A device according to claim 1,wherein the file system interface operator is configured to intercept arequest according to the second file system from the external device andto perform the request using the first file system.
 5. A deviceaccording to claim 4, wherein the file system interface operator isconfigured to respond to the request with a response in a responseformat of the second file system.
 6. A device according to claim 4,wherein the request comprises a request to perform an operation on atleast one logical storage element of the second file system, for examplea request to read or write at least one logical storage element of thesecond file system.
 7. A device according to claim 6, wherein the filesystem interface operator is configured to translate the request into arequest according to the first file system.
 8. A device according toclaim 7, wherein the file system interface operator is configured totranslate the request into a request to perform an operation on at leastone logical or physical storage element of the first file system, forexample a request to read or write at least one logical storage elementof the first file system.
 9. A device according to claim 4, wherein thefile system interface operator is configured to respond to a readrequest by the external device by providing a response that comprises atleast one logical storage element of the second file system.
 10. Adevice according to claim 6, wherein each logical storage element of thesecond file system comprises a block or a sector.
 11. A device accordingto claim 1, wherein the file system interface operator is configured torespond to a read request for the boot sector of the physical storagewith a response that indicates that the physical storage is formattedaccording to a file system of the second type.
 12. A device according toclaim 1, wherein the file system interface comprises representations offiles, directories and/or sub-directories in the second file system thatcorrespond to files, directories and/or sub-directories stored in thephysical storage under the first file system.
 13. A device according toclaim 1, wherein the file system interface operator is configured toupdate the file system interface in response to changes to files,directories or sub-directories stored in the physical storage under thefirst file system so that the file system interface represents thechanges as occurring under the second file system.
 14. A deviceaccording to claim 13, wherein the file system interface operatorrepresents the changes as occurring under the second file system bymodifying metadata of the second file system.
 15. A device according toclaim 1, wherein the file system interface is configured to represent atleast some of the data stored on the physical storage under the firstfile system as being stored under the second file system, and torepresent at least some of the data stored on the physical storage underthe first file system as being stored under at least one further filesystem.
 16. A device according to claim 1, wherein the first file systemcomprises an Ext-type file system, and/or the second file systemcomprises a FAT-based file system or NTFS file system.
 17. A deviceaccording to claim 1, wherein the physical storage comprises NAND flashstorage, and the first file system comprises a log-structured filesystem, for example JFFS2. 18-19. (canceled)